Business Analyst Community & Resources | Modern Analyst

What is MoSCoW and how is it beneficial for prioritizing requirements?

Chris Adams — Wed, 02 Nov 2022 03:52:00 GMT

MoSCoW is a method used to prioritize functional and non-functional software requirements. Developed by Dai Clegg, the MosCoW method was first used as part of RAD (Rapid Application Development) then gained traction as part of the more agile Dynamic Systems Development Method. MoSCoW is an acronym which stands for:

M – Must Have

S – Should Have

C – Could Have

W – Won’t Have but Would Like in the Future

While requirements are often categorized numerically on a 3, 4, or 5 point scale, the MoSCoW method provides the added benefit of providing a pneumonic that qualitatively describes HOW requirements should be classified into each level of priority.

Must Have describes requirements that have to be implemented to have a successful system. There are no workarounds if the functionality is missing. So, if even a single “Must Have” requirement is not implemented the system is a failure.

Should Have describes requirements that if missing would significantly affect the usability of the system but for which a workaround exists. It’s not necessarily pretty or ideal but if you leave a “Should Have” requirement out the user can still manage to use the system, even if their productivity is reduced.

Could Have describes requirements that if missing do not have a dramatic impact on the usability of the system. They are nice to haves. They are still desired because they result in moderate improvement in usability and improve user satisfaction.

Won’t Have but Would Like in the Future describes requirements that are known to be outside of the current scope of the project. These may be nice to have requirements but could also be very significant requirements that merely cannot or will not be included in the current release. This category is used as a parking lot to organize future requirements.

Can the MoSCoW method be used in Agile?

Absolutely, yes! The MoSCoW method works really well within agile as it helps the practitioner identify the MVP (Minimum Viable Product) by considering all the must-have requirements. Once the project team completed all the must-have requirements, they can focus on the the next level, the should-have. Of course, the team should re-prioritize using MoSCoW after each iteration or program increment as could-have and even't won't have requirements may become must-haves.

MoSCoW is one of the core practices of the Dynamic Systems Development Method (DSDM).

Does the MoSCoW method only work for requirements?

Definitely, not! Anything which needs to be prioritized can be prioritized using the MoSCoW method. Here are some examples of prioritization using MoSCoW:

Prioritizing initiatives or projects within a larger program
Prioritizing training courses being considered for a development team

What factors can be used to determine the category of an item using MoSCoW?

When prioritizing requirements (or anything else) it is best to identify the factors which are important to the organization and which should be used when determining the relative priority using the MoSCoW method. Each factor can be given a score and weight which, when added together, can be used to more objectively differentiate between the requirements.

Some factors to consider when determining the priority of a requirement:

cost to develop the requirement
expected benefits of implementing the requirement
regulatory demands
team's ability (skills) to implement

What is the Abilene Paradox and its impact to projects?

Adrian M. — Mon, 11 Jul 2022 03:06:00 GMT

The Abilene Paradox is that phenomenon which occurs when a group of people make a decision together which is counter to what the majority of the individuals or the group actually think or want.

It's an example of negative groupthink and communication breakdown which occurs when individual members of the group believe that their own opinion or preference is counter to what the group wants, without realizing that others are thinking the same way.

The Abilene Paradox can occur in the most polite and civil environments where each group member may mistakenly assume that the group wants and chose to not raise any objections in order to not "rock the boat".

This phenomenon was first introduced by Jerry B. Harvey in an article titled "The Abilene Paradox: The Management of Agreement". Oddly enough, what Harvey noticed is that this occurs when the group is ineffective at managing agreement. Unlike managing disagreement when a group can't figure out how to come to a resolution or compromise, the Abilene Paradox occurs when individual members of a group do not raise concerns about the group decision even though, deep down, they do not agree with it.

So how can the Abilene Paradox impact your project?

Imagine a business analyst, on a large software development project, simply jotting down a critical decision or important requirement decided by a group of stakeholders against common sense and against the individual stakeholders judgement and expertise. Imagine that requirements is now implemented and deployed to production only to find out that's not what anybody wanted.

If you had the feeling and thoughts that it's the wrong decision, would you go against the grain and raise your hand?

Do you have what it takes to question the expertise of the subject matter experts?

How can you spot and avoid falling in the trap of the Abilene Paradox?

Avoiding the Abilene Paradox

As a business analyst, you need to recognize that agreement is not always good - especially when the problem is complex yet the agreements develops very quickly. Before we can avoid it, we must first understand why the Abilene Paradox occurs. Here are a some of the reasons:

Fear of being wrong - what if my idea is a bad one?

Fear of rejection - what if they don't like my idea?

Laziness to fight for a point of view - well, if that's what everybody wants, it's fine with me?

Fear of conflict - the team is working so well together, I don't want to be the one causing conflict?

To avoid falling into the Abilene trap, the business analyst should:

Look for and recognize when complex decisions are made in record time without disent.

Have one-on-one conversations with individuals from the group to get their opinion on the decision

Ask the group: "What would others think of this decision?"

Ask the group: "Do you see any issues with this decision?"

Encourage open communication to ensure everyone's opinion is heard.

Reward and recognize dissenting opinions and thoughts.

What is the difference between horizontal and vertical prototyping?

Chris Adams — Thu, 09 Jun 2022 16:07:00 GMT

Horizontal and vertical prototypes are sometimes used during the analysis and design phases of application development. They are useful for requirements elaboration and visualization, but can present some pitfalls. As long as analysts and teams are aware of the pitfalls to avoid, the pros of using prototypes generally far outweigh the cons. The type of prototype that should be used (horizontal prototype versus vertical prototype) depends on the specific goals of the team and the stage within the analysis and design process.

Compare a user story versus a use case. What are the essential elements of each? When would you use one versus the other?

Chris Adams — Sat, 08 Jan 2022 22:08:00 GMT

The essential elements of a user story are:

The user
Statement of what the user needs to accomplish
Why the need to accomplish this

The essential elements of a use case are:

The Actor carrying out the use case
Summary of the use case
Success criteria
Scenario detailing the steps the Actor follows to achieve the success criteria.

What are the Business Analysis Knowledge Areas?

Chris Adams — Tue, 07 Dec 2021 20:56:00 GMT

This question is an easy way for a hiring manager or an HR professional to screen out candidates who may have under-invested in their career or may lack understanding of the business analysis profession. The 6 Knowledge Areas are:

Elicitation & Collaboration
Requirements Analysis & Design Definition
Solution Evaluation
Requirements Life Cycle Management
Business Analysis Planning & Monitoring
Strategy Analysis

How would you handle a difficult or disruptive person in a group requirements gathering session?

Chris Adams — Mon, 08 Nov 2021 16:01:00 GMT

There are many reasons why people may come off as disruptive in requirements gathering sessions. These might include being resistant to change, being worried you will automate them out of a job, or having been through sessions like this before with no result, which leaves them feeling that the meeting is a waste of time.

Here are some tips to deal with disruptive team members:

How do you engage the right stakeholders for a business analysis activity such as a workshop?

Chris Adams — Thu, 07 Oct 2021 17:33:00 GMT

Business Analysts use powerful tools to get the right information from the relevant stakeholders, an example of a tool could be a workshop. To make the most of it, you need to select and engage the right stakeholders. But how do you know which stakeholders to select?

Why bother with identifying use cases? Why not jump straight to process flows?

Chris Adams — Thu, 07 Oct 2021 16:15:00 GMT

Whether documenting business processes or systems processes, use cases and process flows can both be valuable tools.

A use case description textually describes the main success scenarios of a process as well as the major alternate scenarios and exception scenarios. Process flows do the same thing, though in graphical form. A process flow documents the step by step activities of the main success scenario. Decision points (often shown as diamond shapes) show where the main scenario branches off into alternate scenarios.

What does it mean to be a strong meeting facilitator?

Chris Adams — Mon, 09 Aug 2021 15:22:00 GMT

When looking for Business Analyst roles, many job descriptions are now looking for people who, you guessed it, have excellent facilitation skills. So, in hopes of sparing you any surprises in an interview, I thought I'd give you my words of wisdom on the subject.

Fortunately, you've been practicing facilitation, like I have, without realizing it. So it won't be too hard to catch on…

What preparation should be completed by the BA prior to a Requirements Interview?

Chris Adams — Fri, 07 May 2021 16:40:00 GMT

The steps involved in preparing for a requirements interview are just as important (perhaps even more important) as the act of conducting the requirements interview itself. The quality of the requirements obtained during the interview is closely dependent upon the preparation done upfront. The business analyst should:

What are the 5 W questions (plus H)?

Adrian M. — Sun, 18 Apr 2021 22:52:00 GMT

The term “5 W questions” refers to the five basic questions commonly asked when gathering information. These interrogative words are also known as the 5 W and 1 H.

These questions are not to be used mindlessly but are very useful to get you started in your interviewing sessions and in requirements gathering.

When you are stuck and can’t figure out where to start, the 5 W questions provide one of the best frameworks to get you going.

What techniques do you use to plan and conduct requirements elicitation workshops?

Chris Adams — Fri, 09 Apr 2021 16:10:00 GMT

Prepare participants for the discussion by distributing supporting material prior to the workshop. Send out draft documents, straw model diagrams, or even just a list of questions designed to stimulate thoughts and ideas. Participants will be much more able to articulate their own ideas and respond to others when they’ve had some time to think about the workshop topics in advance.

What is Stakeholder Analysis and how does it benefit the business analyst?

Chris Adams — Fri, 09 Apr 2021 16:00:00 GMT

Stakeholder Analysis is the process of identifying project stakeholders, how their needs may impact the project, and the contributions that the stakeholders will make to the requirements elicitation process. Projects typically have a large number of stakeholders from many different areas of the organization. Based on each stakeholder’s position and responsibilities, the level of their involvement and their importance to the project will vary.

Is it a Defect or is it an Enhancement? How to manage the disagreements.

Chris Adams — Tue, 06 Apr 2021 19:25:00 GMT

“It is a defect, or an enhancement” is one of those arguments in software development that never seems to satisfy anyone when someone makes a decision. I’ve gone so far as to say it is a defectment. It’s really a combination of both. However, that doesn’t necessarily answer the question - nor provide guidance to a resolution.

Describe some pros and cons of using templates that aid in creation of BA deliverables.

Chris Adams — Fri, 12 Mar 2021 17:53:00 GMT

Templates can be useful, but with many tools available to the business analyst they come with their pros and cons.

How do you ensure that your use case model is effective?

Chris Adams — Fri, 12 Mar 2021 17:38:00 GMT

Use case models include actors and use cases. An effective model must identify both comprehensively. Yet, analysts usually fail to identify all of the relevant actors.

To solve this problem, I like to recommend an approach that maintains a separate use case diagram and actor diagram. Then, the actors from the actor diagram can incrementally be added to the use case diagram as the use case diagram evolves.

How would you build a Business Process Model?

Chris Adams — Mon, 09 Nov 2020 03:31:00 GMT

Building a Business Process Model is a complex task that requires a number of successful steps to complete.

1) Determine scope

2) Gather background information

3) Conduct interviews

4) Begin Modeling

5) Validate and iterate

How should the Business Analyst begin the requirements elicitation process for a new product or solution?

Chris Adams — Sun, 10 May 2020 22:00:00 GMT

When beginning analysis on a product or solution that is needed to meet a business need, the Business Analyst needs to obtain a basic understanding of the pain points that the business wants to address.

At this stage of this process there is only a need to get the equivalent of a business executive’s point of view. That is, the analyst needs to get a high level understanding of the pain points, framed through the six basic questions someone needs to ask in order to understand any object: Who, What, Where, When, How, and Why. Let’s take each of them in turn.

What is a Stakeholder Story and how does it compare to a User Story?

Chris Adams — Sun, 12 Apr 2020 19:59:00 GMT

A User Story is perhaps the most widely used Agile technique. It is used to capture product and system requirements from the perspective of the user. Is it the fundamental building block of the Product Backlog. A stakeholder story expands the scope of requirements to non-users of the system.

Why would the Business Analyst use Kano Analysis?

Chris Adams — Sun, 12 Apr 2020 18:20:00 GMT

Kano Analysis refers to the process of analyzing a product or system requirements to determine what the perceived impact will be on customer satisfaction.

The Kano model categorizes product attributes or system requirements into 3 categories to determine the perceived customer satisfaction: Unexpected Delights, Performance Attributes, Must Have Attributes.

What is the H-Method and how can it benefit the Business Analyst?

Chris Adams — Mon, 11 Nov 2019 14:30:00 GMT

The H-method is an analysis tool that aids the BA in organizing a fact finding interview with a business representative or system user.

How are personas used in requirements elicitation on agile projects?

Chris Adams — Sun, 13 Oct 2019 22:30:00 GMT

A persona is a description of a fictional person, representing key characteristics of a specific user class or group. Personas provide models of the user community that make it easier for project teams to understand and predict how users will act and react, based on characteristics such as age, education, knowledge, and attitudes.

A key purpose that personas serve on agile projects is in the formulation of user stories, so that each story is written from the perspective of a distinct person with known attributes – rather than a generic “user” or job role.

Personas are also invaluable in making design decisions, and determining how usability can be optimized for the user community.

As with all other aspects of Agile projects, personas should be developed collaboratively amongst the team and refined iteratively over the course of the project.

Here is a short video that highlights the need to validate personas against real data and real user information, as well as the benefits of building personas iteratively as more information becomes known – The Secret to Developing Effective Personas.

--
Sandy Lambert
Business Architect
LinkedIn Profile

What is Active Listening and how can it benefit the business analyst?

Chris Adams — Sun, 13 Oct 2019 18:45:00 GMT

Active Listening is a method used to listen and respond to others in a structured and deliberate way. It requires a listener to understand and actively evaluate what he or she heard.

What is a Product Manager?

Chris Adams — Sun, 07 Jul 2019 16:00:00 GMT

The role of the Product Manager resides at the intersection between business, technology and user experience. The paramount responsibility of a Product Manager is to ensure that the product they manage (software, service, or other tangible product) creates value for the business. In turn, to create value for the business the product needs to be of value to customers or to internal business employees.

How do you resolve an issue involving conflicting requirements from two or more stakeholders?

Chris Adams — Sun, 07 Apr 2019 20:10:00 GMT

In order to determine what action should be taken to resolve conflicting requirements, the analyst must first determine the root cause of the conflict. The causes of conflicting requirements are typically the same, time and time again.

What is the 90-9-1 rule and how can a business analyst take advantage of it?

Chris Adams — Thu, 07 Feb 2019 17:30:00 GMT

The 90-9-1 rule is a popular concept among marketing professionals, but has a much wider application which can serve a business analyst well. The basic principle is that the behavior of a community of people (or a group of users) naturally falls into 1 of 3 groups with the relative population sizes of 90%, 9%, and 1%.

How does the Business Analyst role change on an Agile project compared to projects using other software development methodologies?

Chris Adams — Mon, 12 Mar 2018 15:02:00 GMT

The role of the BA should actually change very little between different software development methodologies, although the tools and techniques used by the BA can vary according to the needs and attributes of any given project or development lifecycle.

The core responsibilities of a BA on a software development project include requirements elicitation, requirements analysis and requirements management – regardless of the project methodology. The type and format of requirements documentation are just tools, and a good BA has a wide range of tools at his or her disposal.

What are Scenarios within the context of User-Centered Design?

Chris Adams — Mon, 15 Jan 2018 02:20:00 GMT

User-Centered Design (UCD) is an application design methodology which focuses on usability goals, user demographics, real-world environment, tasks, and workflow in the design of an application interface. During the analysis phase of UCD, two key stages are the User Analysis stage and the Workflow Analysis stage.

Describe the life cycle of a User Story?

Chris Adams — Mon, 09 Oct 2017 15:20:00 GMT

User Stories are used by agile methodologies to capture the functionality that a system or software should support. For details about what a user story is and how to write one reference What are User Stories.

What are some steps the Business Analyst can take to avoid vague, incomplete or ambiguous requirements?

Chris Adams — Sun, 09 Apr 2017 20:55:00 GMT

Stakeholders often interpret requirements in a variety of different ways. Whether its from the natural ambiguity of conversational language or due to missing information, ambiguous and incomplete requirements can lead to project delays and budget overruns. But by keeping a few key considerations in mind the Business Analyst can dramatically improve the quality of product requirements.

What types of actions can help the business analyst avoid Analysis Paralysis?

Chris Adams — Sun, 12 Feb 2017 22:10:00 GMT

Analysis Paralysis is the dreaded black hole of projects. So, how do you recognize that you might be in Analysis Paralysis. Here are a few symptoms that might clue you in.

How can the acronym INVEST assist the analyst during the development of user stories?

Chris Adams — Sun, 12 Feb 2017 11:56:00 GMT

INVEST is an acronym that can help a Product Manager or Developer create quality user stories. INVEST stands for Independent, Negotiable, Valuable, Estimable, Sized-Appropriately, Testable.

I - Independent: The user story should be self-contained if at all possible to avoid dependencies on other user stories. Since one characteristic of agile methodologies is the ability to be flexible and re-prioritize what’s important, independent user stories allow for flexibility during iteration planning. If you do find that your user stories are dependent upon one another, you may be able to combine smaller user stories together that have a dependency between one another. Similarly, you can divide larger dependent user stories into smaller stories such that one of the new smaller stories contains and isolates the overlapping portion of the larger stories.

N - Negotiable: User stories can always be changed or rewritten up until the point of coding. This further supports the flexibility associated with agile methodologies. Since requirements often evolve or rise and fall in priority, user stories should be able to adapt with the changing requirements.

V - Valuable: A user story represents a goal of an end user or purchaser and should deliver functionality that is deemed valuable. This means that specifics of the technical design are not something that you would document as user stories. However, some technical requirements have a component which is valuable to a user. A user might expect pages to load within 2 seconds. The user story would specify the need for 2 second page load times while the specifics of the physical implementation of this would be left out.

E - Estimable: You should always be able to estimate the size of a user story. Sometimes, developers won’t have the experience required to size a particular situation or needed for a user story. When this occurs the user story can be split into two separate user stories. The first is a “spike” which is where developers do some quick research to determine the feasibility of something or get a better idea of how long it might take to implement the particular feature. The spike is always time-boxed, meaning it is limited to a pre-defined amount of time. The “spike” user story might be named “Research (something) to determine…)”, while the second user story is where the functionality will actually be delivered. These two user stories should be scheduled into two separate iterations such than the spike can be completed and the feasibility of the second user story assessed before coding begins. This gives the team time to react if problems arise from the spike.

S - Sized Appropriately: User stories shouldn’t be too big or too small. So how do you decide what size is right. First, any user story that can’t be completed by a developer within a single iteration (or by a developer pair when paired programming is being used) is too big. The user story should be subdivided into two or more smaller stories. Similarly, there is no need to make user stories too granular just for the sake of decomposing features. If features group well together and complement each other then it makes sense to make a single user story. For instance, “As a job seeker I want to be able to add, delete, and edit a job skill on my electronic resume so that I can maintain an accurate listing of my skills.” There is no reason to split “add, delete, and edit” into multiple user stories unless one of them creates a significant amount of work that would make the user story too large for the iteration.

T - Testable: User stories must be testable in order to ensure that development is complete and has been done correctly. So when are user stories not-testable? Often, if the analyst isn’t carful, non-functionality requirements are written in a manner which is un-testable. Consider the example, “pages should always load quickly”. There are two un-testable components of this statement; “always” and “quickly”. A testable statement would be “pages should load within 1.5 seconds 97% of the time”.

--
Chris Adams
LinkedIn Profile

What are some pros and cons of using screen mockups for requirements elicitation?

Chris Adams — Sun, 08 Jan 2017 21:10:00 GMT

Screen mockups can support the requirements gathering process when introduced at the right time, but if introduced too early they can become problematic.

What is a focus group and how do you conduct one effectively?

Chris Adams — Sun, 11 Dec 2016 21:22:00 GMT

A focus group is an interactive guided discussion with a carefully selected group of people (usually demographically diverse) used to obtain feedback about a product, service, or concept. A focus group can be conducted before a launch and/or afterwards for ongoing feedback. Open-ended questions are asked to the group and participants are encouraged to respond and interact freely with other group members. As the facilitator guides the conversation either a scribe will take notes or a video recording may also be made for further analysis and review at a later time. Focus groups typically last for one to two hours.

Describe the requirement engineering process SQUARE.

Chris Adams — Sun, 11 Sep 2016 00:00:00 GMT

SQUARE stands for Security Quality Requirements Engineering. It is a requirements engineering process developed by Carnegie Mellon University’s Software Engineering Institute (SEI) which focuses on eliciting and documenting security requirements. Since security requirements are often not given the focus that they deserve and since trying to incorporate security requirements later in the software development lifecycle costs more than planning for them upfront, the SEI developed a nine-step process to ensure that quality security requirements can be gathered, categorized, prioritized, and validated early on in the software development lifecycle.

What is Document Analysis?

Chris Adams — Sun, 14 Aug 2016 20:30:00 GMT

Document Analysis is a technique used to gather requirements during the requirements elicitation phase of a project. It describes the act of reviewing the existing documentation of comparable business processes or systems in order to extract pieces of information that are relevant to the current project, and therefore should be consider projects requirements.

What are the benefits of a developing a business entity model early in the analysis process?

Chris Adams — Sun, 10 Jul 2016 21:00:00 GMT

There are numerous benefits to developing a business entity model (also called a logical data model), early in the analysis process. To understand these benefits, the information captured in the business entity model needs to be understood.

What might lead a Business Analyst to inadvertently make a wrong decision?

Chris Adams — Sun, 10 Apr 2016 18:45:00 GMT

Bad decisions (or at least not the best decision) are made more frequently by business analysts than one might expect. This is often due to a number of biases that occur when gathering information and analyzing patterns and trends.

What is Brainswarming and how does it compare to Brainstorming?

Chris Adams — Sat, 12 Mar 2016 20:37:00 GMT

Brainswarming is a problem solving technique which questions why we really need to talk in the first place.

What is a Fact Model?

Chris Adams — Sat, 12 Mar 2016 18:00:00 GMT

A Fact Model is a static model which structures business knowledge about core business concepts and business operations. It is sometimes called a business entity model.

How do you avoid requirement conflicts while making changes to an existing system where no documentation exists?

Chris Adams — Sun, 13 Dec 2015 20:41:00 GMT

Companies with small IT departments or analysis teams often lack a well defined analysis process. It's not uncommon for analysts to be hired onto a team and find that they are being asked to assist with requirements and new features for a system where no documentation exists. In this case, the analyst needs to create a minimal amount of documentation retroactively.

What are User Stories?

Chris Adams — Sun, 13 Dec 2015 16:00:00 GMT

Extreme Programming (XP), one of many Agile methods, introduced the practice of User Stories to describe what a system or piece of software should do. User stories have since been adopted by many of the agile methods used today.

User Stories are short descriptions of functionality that will be valuable to a user or purchaser of the software or application. They describe the users’ goals when using the system. The initial descriptions can be written by the users, customers, product managers, or developers, and are just a few sentences at most (1-3 sentences being typical). This isn’t the entire user story, but it is all that is created at first.

The development of user stories occurs in three parts; the Card, the Conversation, and the Confirmation.

The Card: Named for the standard index cards on which a user story is often captured, Cards include the brief description of the user story, its relative size to other user stories (called story points), and the priority of the functionality. The cards are used for planning the work that will be completed during each iteration of development. If the size of the user story gets too big to complete within a single iteration then it should be broken into smaller stories. The term used to describe a user story which needs to be further broken down into smaller stories is an “Epic”.
The Conversation: While the conversation itself is not an actual deliverable, it is a critical step in the user story development process. Discussions about each user story are had with the users/customers of the system to flesh out details. The details of the conversations are documented in the form of acceptance tests called “The Confirmation”.
The Confirmation: Acceptance tests are details which are captured from the Conversation that can be used to verify that the user story has been successfully implemented. When index cards are used, the acceptance tests are typically written on the back of the card itself. Acceptance tests can and should be captured whenever they are thought of, however, at the beginning of each iteration there is a defined period of time which is set aside to generate acceptance tests.

Using these three parts, the goal of the user story is to plan which functionality will be developed during each iteration, provide enough detail that a developer pretty much understands what needs to be coded, and provide a means to verify that they have achieved the goal. If the developer needs more details, more conversations are had, the details of which are documented as more acceptance tests.

Here are some sample user stories (the Card) for a job board:

I want to post a resume
I want to search for a job
I want to electronically submit my resume for jobs I like

Some user stories follow a more formal structure than others. One formal approach suggested by Mike Cohn follows the structure: “As a (role) I want (something) so that (benefit)”. At first, structuring your user story descriptions like this may seem like overkill sometimes, but it makes sure that you aren’t forgetting WHO you are designing the functionality for and WHY.

As a job seeker I want to post my resume so that recruiters and employers can find it.
As a job seeker I want to search for a job so that I’m in control of my job search.
As a job seeker I want to electronically submit my resume for jobs I like so that I increase the changes of receiving an interview.

Here are some acceptance tests for the user story, “I want to search for a job”

Test with keyword, salary, and location search parameters
Test that the search results are returned in 2 seconds or less

Some comparisons can be made between user stories and use cases, but there are key differences that should be remembered.

Size and Scope	User Stories have limited scope to fit within an iteration.	Use Cases are almost always larger in scope than user stories.
Structure	User Stories typically represent a single scenario or path through a use case. This could be the main scenario, or an alternative or extension path. Remember that the user story includes the acceptance tests which often describe the details covered in alternative and extension flows.	Use Cases represent a series of related user scenarios. While a main scenario (often the most common scenario) is selected, there are many decision points throughout the flow that branch into alternative or exception flows.
Purpose	User Stories are created to facilitate conversation between the client and development team when the time is right, and have the primary purpose of supporting release and iteration planning process. They are never referred back to as a contract between teams.	Use Cases are written to be understood by both the client and the technology team. They represent a written contract of the desired functionality.
Completeness	User Stories are intentionally written at a goal level initially with just enough detail to describe the user story with just a few sentences at most. Only once the iteration planning begins and more detail will be required the team has conversations to capture acceptance tests.	Use Cases are completed in their entirety early in the analysis and design process. Because of this there exists a natural urge by the customers to place screen specific elements in the use cases themselves, even though there is usually a very strong push by the technology team to try and avoid this. Inevitably the technology team rarely succeeds in keeping UI features out of the use cases.
Longevity	Typically User Stories are not intended to live beyond the iteration in which they are developed. Once the functionality has been developed they are discarded.	Use Cases are often saved and become permanent artifacts representing a permanent contract between the customer and development team.

--
Chris Adams
LinkedIn Profile

What techniques do you use to keep a workshop discussion on track when participants act in a confrontational manner, or try to dominate the discussion with their own particular issues and concerns?

Chris Adams — Sat, 05 Oct 2013 17:33:00 GMT

This situation is probably familiar to most (if not all) Business Analysts, and there are some specific facilitation techniques to keep participant engagement focused and collaborative.

The first essential step is advance preparation. Top facilitators learn as much as possible about participating stakeholders’ needs and concerns in advance. With this knowledge, the facilitator is able to effectively engage each of the participants in the discussion and is prepared to respond when concerns are raised.

When any issue is raised in a workshop, acknowledge its importance to the participant who raised it. People need to know that their concerns are heard and acknowledged – and will repeatedly voice their concerns until that happens. Once the issue is acknowledged, then it can be parked for follow-up outside of the workshop. An example facilitator response is: “I can see this is important to your team. I’d like to spend some time discussing it with you and make sure we take the best direction forward. Can I set up a separate meeting with you next week?”

Anytime an item is parked, there should be a clear action plan and timeline for any follow-up required. It is important to ensure that follow-up occurs as planned, to build and maintain stakeholder trust.

These techniques will help keep workshops productive and stakeholders engaged.

--
Sandy Lambert
Business Architect
LinkedIn Profile

What are 2 common attribute categories sometimes used to extend the Kano Model?

Chris Adams — Sun, 07 Aug 2011 22:08:00 GMT

Kano Analysis refers to the process of analyzing a product or system requirements to determine what the perceived impact will be on customer satisfaction.

The Kano model categorizes product attributes or system requirements into 3 primary categories to determine the perceived customer satisfaction.

Unexpected Delighters
Performance Attributes
Must Have Attributes

In addition, the Kano Model is often extended by differentiating attributes into two other categories:

Indifferent Attributes: These are attributes of a product or system that the customer doesn’t really care about one way or the other.

My smart phone example: Cellular network technology (CDMA, GPRS, GSM, etc) is for most customers an indifferent attribute. Very few customers care about the type of technology used as long as it doesn’t directly impact the quality of their service.

Reverse Quality Attributes: These are attributes of a product or system that can best be described as “more isn’t always better”. You can also consider these to be the opposite of Delighters. If the feature or attribute doesn’t exist then no big deal. However, if it does exist or it’s not designed properly, then it can create dissatisfaction. An example explains these best.

My smart phone example: Too many features can be an example of a Reverse Quality Attribute of a smart phone. You can view this from a perspective of usability. If many features are added to a smart phone but it creates an overly complicated user experience due to poor user interface design, then it has resulted in a Reverse Quality experience and customer satisfaction declines.

How would the Pair-Choice technique be used with requirements?

Chris Adams — Sun, 07 Aug 2011 22:03:00 GMT

The Pair-Choice technique is a prioritization technique that can be used in single person or group settings. However, it is most often used as a consensus building technique when multiple stakeholders are involved. The pair-choice technique is applied when the audience is having difficulty rank ordering the importance of items. These items might be requirements, but they can also be any number of other items that require prioritization.

The Pair-Choice technique asks the audience to compare each item against every other item (pairing) and as a group choose which one is of higher priority (choice).

The sample table below shows the pair-choice technique applied to 9 items.

As you can see when item 3 was paired with item 7, it was determined that item 7 was of higher priority.

After the exercise is complete, the number of times an item “won the choice” is tallied up as seen below.

A clear ranking begins to emerge. When ties are found in the tallied results, the table can be used to see which item ranked higher. In the case of item 3 and 5, 3 won the pair-choice so it would be ranked higher than 5.

What are some key characteristics of good set of Requirements Interview questions?

Chris Adams — Sun, 12 Jun 2011 20:53:00 GMT

In order to walk away from the requirements interview with good requirements, the questions asked need to be properly thought out and strike the right balance. Here are a few key characteristics that help the analyst produce a set of quality requirement interview questions.

Some questions need to focus on the as-is process.
Other questions should ask about the major pain points in the process or what might be missing.
Questions should be a balance of open-ended and close-ended questions. Close ended questions may not yield as much breadth of understanding, but too many open ended questions can make it difficult for the interviewee to give that analyst structured or relevant feedback (i.e., avoid too many questions that start with “Why”).
Ensure that the questions are not leading questions which imply an answer; this can negatively influence the information that the analyst receives.
Keep it brief. The primary list of questions should be only 7-10 high level.
Each primary question may have a number of more specific follow up questions.

Describe the Elicitation knowledge area of the BABOK and its key tasks (BABOK v2.0)?

Chris Adams — Sat, 06 Feb 2010 21:02:00 GMT

How do you define the term Requirement?

Chris Adams — Sat, 06 Feb 2010 20:55:00 GMT

What techniques do you use to ensure that you have identified the principle problem or requirement?

Chris Adams — Sat, 04 Apr 2009 21:40:00 GMT

Problem solving and problem resolution is a common part of a business analyst’s role. But before you spend time figuring out resolutions to the problem, you should be sure that you’re solving the right problem or that you have the true requirement.

Problem Restatement is one category of techniques that can be used to determine that the principle problem has been identified. Some problem restatement techniques are:

Problem Paraphrasing – Alter the wording of the problem statement just slightly resulting in a new problem statement which is very similar in meaning. Repeat the process until you have arrived at the principle problem.
5W + 1H (Who, What, When, Where, Why, + How) – Create multiple variations of the problem statement beginning each statement with one of the 5W + 1H keywords.
Repeatedly Ask Why – Starting with the original problem statement, ask ‘Why’ to identify a new problem statement. Continue to ask why to each new problem statement until you arrive at what is clearly the principle problem.

Give an example of how you would use the problem restatement technique of ‘Repeatedly Ask Why’.

Chris Adams — Sat, 04 Apr 2009 21:33:00 GMT

The Repeatedly Ask Why technique starts with the original problem statement and asks ‘Why’ to identify a new problem statement. The Business Analyst continues to ask why to each new problem statement until he or she arrives at what is clearly the principle problem.

This technique is so natural that all of us have used it as toddlers. Using the ‘Repeatedly Ask Why’ technique allows the Business Analyst to overcome any assumptions that may have been made when developing the original problem statement. So revert back to that 2 year old kid and ask ‘Why’.

Example:

We need a new cafeteria vendor at our company campus. – Why?
Because the quality of the food continues to get worse. – Why?
Because they keep reusing leftovers and using lower quality products. – Why?
Because they are trying to make enough money to be profitable. – Why?
Because over the last few months fewer people have been going to the cafeteria. – Why?
Because we had layoffs and there are less people on our company campus.

At this point we can identify that the principle problem is the layoffs resulting in fewer people using the cafeteria. No matter what vendor you hire, they will have troubles being profitable under these conditions. So the original problem statement stating that a new vendor is needed is incorrect.